Multicast implementations in enterprise servers generally fall into two categories: unreliable and reliable. Unreliable implementations, as might be expected given the name, are used in applications where it is okay if content is missed by the receiver. An example of this is a broadcast of a company meeting. If a client device misses a packet, the video/audio may skip a little, but the server should not have to resend the packet—the client's receipt of the one missed packet is not critical. Reliable implementations, by contrast, are used in applications where it is mandatory that the client device receive the entire transmission. An example of this is distribution of a security hot fix or patch. If a client misses a portion of the transmission, the client may have received an incomplete hot fix and thus still be vulnerable to the security flaw.
In present multicast implementations, in order to provide reliability the end-to-end principle indicates that each client device (receiver) should send messages back to the multicast server (sender) to acknowledge receipt. This then raises a problem with scalability, as too many messages coming back may implode upon the sender overflowing its incoming network capacity and/or its capacity to process such messages. There is also a scalability issue when the sender must store state information for each receiver, causing its memory requirements to grow with the number of receivers. Reliable multicast protocols typically address scale by using a mix of message suppression, hierarchy, and forward error correction (FEC). Further challenges for reliable multicast are flow control and congestion control, including reasonably fair bandwidth sharing with the standard transport control protocol (TCP) (referred to as being “TCP-friendly”).